These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `light/client.go`:
- [BLOCKING] light/client.go:888-912: A colluding primary and witness can evict the sole honest witness
  This changes the light client from the documented any-honest-witness model to an unenforced provider-majority model. If a malicious primary serves a validly signed non-canonical fork, one colluding witness returns the same header, and the sole honest witness returns the canonical header, the counters are one corroborating and one conflicting witness. The code removes the honest witness and then persists the primary's fork. Witness comparison exists specifically to detect an otherwise valid conflicting fork after validator trust assumptions have failed, and `docs/tendermint-core/light-client.md` currently says the client is unsafe only when all witnesses are malicious. Fail closed when both sides provide conflicting valid headers, or explicitly adopt, document, and enforce a suitable honest-majority provider model rather than automatically selecting the primary's side.
- [BLOCKING] light/client.go:883-909: Sequential removals use stale witness indices and can panic
  `conflictingWitnesses` stores indices from the original witness slice, but `removeWitnesses(witnessesToRemove)` first reorders and truncates that slice using swap-with-last. With witnesses `[matching, bad, conflicting]`, removing bad index 1 moves the conflict to index 1 and leaves a two-element slice; the subsequent log evaluates `c.witnesses[2]` and panics. Other orderings can remove the wrong provider instead. Do not mutate `c.witnesses` until every provider selected for removal has been captured; if dissent removal remains after resolving the security issue above, combine all indices into one removal operation and add a regression test containing matching, bad, and conflicting witnesses together.

In `light/proxy/proxy.go`:
- [BLOCKING] light/proxy/proxy.go:123: Same-host fallback permits DNS-rebinding WebSocket access
  `OriginChecker` trusts the request's unvalidated `Host` header whenever it matches the Origin host, even when the configured allow-list is empty. An attacker can serve a page from `http://evil.example:8888`, rebind that hostname to the victim's loopback or private address, and connect to `ws://evil.example:8888/websocket`. The browser then sends both `Origin: http://evil.example:8888` and `Host: evil.example:8888`, so the check succeeds against the default localhost light proxy. This exposes WebSocket RPC methods, including transaction broadcasting and subscriptions, despite the claimed zero-trust default. Reject Origin-bearing requests unless the origin is explicitly configured, or independently validate `Host` against trusted listener or reverse-proxy hostnames.

In `internal/consensus/state_data.go`:
- [SUGGESTION] internal/consensus/state_data.go:269-280: Unsafe-threshold warning can be skipped and mislabels canonical quorums
  The outer condition does not account for changes to quorum type or total validator power, although both affect `BelowStrictThreshold()`. For example, a same-quorum set with an unchanged explicit threshold of 800 can grow from 11 validators to 12: the strict floor rises from 734 to 801, making the configuration unsafe, but the quorum hash and raw threshold remain unchanged and no error is logged. The message is also factually wrong for canonical thresholds: `DEVNET_PLATFORM` with 12 validators derives an 800 threshold while `VotingPowerThreshold == 0`, so it is below the 801 strict floor without any override. Trigger the check whenever the effective safety inputs change and add the `OVERRIDE ENABLED` prefix only for an explicit override.